…ariant)

A sharded apply fans out across the shards of one keyspace within a single
deployment, but the comment renderer reused the multi-deployment layout, whose
unit is the deployment. Every per-shard operation shares the one deployment
("cake"), so all shards rendered as identical "cake" rows, and — because the
per-deployment Details map is keyed by deployment name — the per-shard detail
collided and a failed shard's error was dropped (it showed a pending sibling's
body instead). That is why a failed rollout surfaced no error.

Add a dedicated sharded layout:
- pkg/webhook/templates/sharded_apply.go: RenderShardedApplyComment. Shards are
  grouped by change signature — a uniform apply renders one Shard|Status table
  with the DDL once; divergent shards (different tables, or the same table
  computing to different DDL because shards drifted) render one group per
  distinct change set, each tying its shards' statuses to the DDL it runs. The
  first failed shard's error is lifted to the top and shown in its row.
- pkg/webhook/sharded_apply.go: detect a sharded apply (work ops keyed
  namespace/shard/table, one deployment), and build the comment input from the
  operation rows + tasks. Per-shard status is derived through pkg/presentation
  with the shard name as the operation identity, so ordering labels reference
  shards ("waiting for -40", "halted — -40 failed") with no presentation change.
  formatApply{Status,Summary}Comment route sharded applies here.

Finalizer (VSchema) operations are out of scope for the shard view for now;
their outcome is still reflected in the aggregate headline state.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…-presentation

The sharded layout only recognised the terminal Failed state, so an apply that
SchemaBot is auto-retrying (failed_retryable) lost its error and its next-action
guidance. Mirror the single-deployment renderer:
- isShardFailureState covers Failed and FailedRetryable; the first-failure
  callout and the per-shard status cell both surface the error for either.
- writeShardedFooter adds the FailedRetryable case with the "stop retrying"
  command, matching writeApplyFooter.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

buildShardedApplyData took only the first task's DDL for an operation. An
operation can carry more than one task for its (namespace, shard, table) when a
shard plan yields multiple statements for the same table, so this dropped
statements and corrupted the change signature used to group shards. Join every
non-empty task DDL in task order instead. Covered by
TestBuildShardedApplyData_JoinsMultiTaskDDL.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

- isShardedApply now also requires every shard work operation to share one
  namespace. A multi-keyspace apply (still one deployment) would otherwise route
  to the sharded layout and mislabel the keyspace / mix unrelated shard groups;
  it now falls back to the existing layout.
- countChanges counts a keyspace's per-shard statements when the collapsed
  namespace-level Statements are absent (keyspaceStatementCount), so a sharded
  plan whose only DDL is per-shard is not miscounted as "no changes" and gets
  correct summary counts.
- Tests for multi-keyspace fallback and per-shard-only plan counting.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…n apply

Apply comment: a remote failure records its error on the operation's task, and
the operator may not stamp it onto the operation row — so the sharded apply
comment showed a failed shard with no error (forcing a trip to logs).
aggregateShardState now falls back to the first task error when the operation
row carries none, so a failed shard always shows why.

Plan comment: an unsafe change confined to one shard (e.g. a column drop on a
single drifted shard) is now flagged with that shard. shardedUnsafeChanges
derives unsafe changes from the per-shard plan (grouped by table+reason → shards)
when present, since the collapsed namespace-level Changes can omit a shard's
change; the unsafe-changes warning names the shard(s).

Tests: apply falls back to task error; plan surfaces a per-shard unsafe change
scoped to its shard (both the builder and the rendered warning).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Copilot fixes:
- parseShardOperationKey rejects keys with extra segments (strict 3-part split),
  so "ns/-40/table/extra" is no longer misclassified as shard work.
- buildShardedApplyData sorts each operation's tasks by id before joining DDL,
  so the joined DDL and the change signature are deterministic (tasks arrive
  created_at DESC). In practice an operation has one task — multiple statements
  for one table are combined into one ALTER upstream — so this is defensive.
- planResponseFromProto drops shard plans with no changes, and buildPlanCommentData
  skips per-shard entries with no DDL, so an empty shard never renders a blank
  section or inflates the change count (a shard is changing iff it has changes).

Control-plane fail-closed guard (requested):
- dispatchPendingApply refuses to dispatch a shard work operation
  ("namespace/shard/table") that resolves no target shard, with a clear error
  naming the skew, instead of sending an empty TargetShards that the data plane
  rejects opaquely as "expected exactly one target shard, got 0".

Also correct the per-shard unsafe test/preview: a same-table change is one
combined ALTER, not multiple statements (multi-statement-per-table is unsupported).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…-presentation

The sharded apply/plan comments weren't represented in the generated
TEMPLATES.md catalog. Add preview renderings (pkg/webhook/templates/
preview_sharded.go) for the divergent plan, the per-shard unsafe-change plan,
and the in-progress / failed / divergent apply comments — per-shard statuses
derived through pkg/presentation so they match production — wire a
comment_sharded_all aggregate preview type, and add a "Sharded Apply" section to
update-templates.sh. Regenerated TEMPLATES.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>